Repository Access Rights (ACLs)

This topic describes how to configure Access Rights (ACLs) for a repository.

In this topic:

Configure Access Rights (ACLs)

GitCentric implements a group-based ACLs security model derived from Gerrit Code Review. This is a powerful tool for defining who can do what with Git repositories under GitCentric control. You will need to have a solid understanding of these group-based ACLs and do some planning before implementing them, so be sure to first read the following section: GitCentric group-based ACLs, and the Gerrit Code Review documentation for details. Use the following general procedure for settings ACLs on your repos.

1. Click the Administration button and then click the Repositories menu. The Repositories page opens.
2. Click the repository you want to configure. Selecting All-Projects will cause all other repositories to inherit whatever ACLs you apply.

   Note: Only the All-Projects system-defined repo has a Global Capabilities section with an Administrate Server permission which gives administrators broad powers across all repos. Be extremely careful when editing this permission.)

3. On the Repositories page, click Access.
4. Use the Rights Inherit From link to specify the repository from which you want the new repository to inherit its access settings. By default, all repositories inherit access rights from the system-defined All-Projects. You can create a parent-only repository to easily apply settings such as this to all child repositories.
5. Click Edit, then Add Reference. In the Reference field, you can accept the default value (refs/ heads/*) to apply the access setting to all branches in repository, or modify it to apply to a specific branch. Specifying refs/* applies the ACL to everything in the repository.

6. Select the permission that you want to apply to this repository from the list.

   

7. After selecting the permission, complete the Group Name field for whom this permission applies in the this repository. The field supports type-ahead, so, for instance, entering R will provide Registered Users as a possible completion.

   

8. Optionally enter a commit message. An admin user can view this when performing a git log refs/meta/config command on the repository.
9. When done, click Save Changes.

Back to top

Configure ACLs for Code Review

Part of enabling the GitCentric’s optional Gerrit Code Review functionality involves setting ACLs for Git references as shown in the following table:

Most of these ACLs are set automatically for the All-Projects repository when you install GitCentric.

There are slight differences based on whether you installed GitCentric 2013.3 for the first time, or you upgraded to GitCentric 2013.3 from an existing installation. If you:

• Installed GitCentric 2013.3 for the first time, all ACLs listed in the preceding table are set as the default for the system-defined "All-Projects" repository. Any repository that inherits rights from All-Projects is also configured to support code review.

• Upgraded to GitCentric 2013.3 from a previous release and you are currently using Gerrit Code Review, you will need to manually set the Submit permission for refs/* as shown in the preceding table. All other permissions (Forge Author Identity, Push, and Label Code-Review) were set as the default for All-Projects when you installed GitCentric.

  If you upgraded from a previous release and are not currently using Gerrit Code Review and now wish to, you must manually set all the ACLs listed in the preceding table.

Once the ACLs are set, all that remains to enable code review is for your users to configure their clones to support code review. For more information, see Configure the clone for Code Review (optional).

Additional Considerations for ACLs

There is no one set of ACLs that are appropriate for every installation. You must analyze the needs of your specific installation and adjust the default ACLs as necessary. See Access Controls in the Gerrit Code Review documentation, specifically the section labeled Examples of typical roles in a project for suggestions about setting Gerrit Code Review ACLs.

The remaining information in this section describes other considerations to evaluate when enabling code review.

Label Verified

The Verified category is generally intended to be used in continuous integration environments where Gerrit Code Review is integrated with Hudson or Jenkins. Typically, the vote for this category is set to +1 by the integration tool indicating that it was able to compile and run tests on the change, allowing the change to be submitted. If you do not have a continuous integration environment, you can either disable the Verified category, or configure the Label Verified ACL in GitCentric to allow users to manually specify a vote via the Gerrit Code Review GUI. The ACL to allow manual voting for the Verified category is shown in the following table.

Configuring "Verify" for Continuous Integration

With Hudson or Jenkins, you would typically set the Label Verified permission for the Non-interactive users group. See the Hudson, Jenkins, or Gerrit Code Review documentation for details about configuring a Continuous Integration environment.

ssh -p 29418 <your_server.com> gerrit gsql
DELETE FROM approval_categories WHERE category_id = 'VRIF';
DELETE FROM approval_category_values WHERE category_id = 'VRIF';

Back to top

Configuring GitCentric ACLs for a direct push

If you do not wish to use GitCentric’s optional Gerrit Code Review functionality, you must modify the default ACLs as follows. (These are simply minimal suggestions. You must analyze your site requirements and customize these settings as appropriate for your specific site.)

1. Change the setting for the Push permission for refs/for/refs/* to BLOCK.
2. Add the Push permission for refs/* and set it to ALLOW.
3. Add the Push Merge Commits permission to refs/* and set it to ALLOW.

You must also have your users adjust the Git config file in each of their clones to remove the following line:

push = refs/heads/*:refs/for/*

Back to top

Configure AccuRev Element ACLs (EACLs)

You can configure Element ACLs (EACLs) on the AccuRev Server for the GitCentric service account, to determine which files can be edited in the GitCentric repository. Files that cannot be edited do not appear in the GitCentric repository.

For details on how to set up AccuRev Element ACLs, see the following links:

• AccuRev Security Overview
• Element-Level Security (EACLs)

Back to top